Can't the same be readily achieved with external data? Have multiple nodes, each with its own load/entry addresses and have them all point at the same external data region.

Hi @a3f ,

Thanks for the suggestion! If I understand correctly, the external data mechanism (mkimage -E) does move binary payloads outside the FIT blob, but it doesn't help with the duplication issue here. If we have M image nodes referencing the same binary, fit_extract_data() in tools/fit_image.c iterates every /images subnode independently and copies each one's data property to a new sequential position in the external area. There is no content deduplication, so the same kernel binary ends up stored M times.

The reference subnode approach avoids this entirely, a single /images/kernel-1 node holds the binary once, and each configuration carries a small subnode (image, load, entry) expressing where to put it. No deduplication logic is needed.

There is no content deduplication, so the same kernel binary ends up stored M times.

Sounds like something that can be changed in mkimage?

No deduplication logic is needed.

The way I see it:

1. We can patch mkimage and existent bootloaders will just be able to make use of it and no spec change is needed
2. We complicate the spec and have to patch bootloaders to make use of this new mechanism

Option 1. is clearly better in my eyes.

Sounds like something that can be changed in mkimage?

Yes, I think so

We can patch mkimage and existent bootloaders will just be able to make use of it and no spec change is needed

If I understand correctly, multiple image nodes sharing the same data-offset is currently undefined behaviour in the FIT spec. The spec defines data-offset only as

data-offset 
    Offset of the data in a separate image store. The image store is placed
    immediately after the last byte of the device tree binary, aligned to a
    4-byte boundary. This is mandatory if external data is used, with an offset.

with no statement on whether offsets must be unique, whether sharing is permitted, or how tools should handle it.

To make this approach well-defined, I feel like we should put it into the spec, and would need to address at least:

1. explicitly permitting multiple nodes to reference the same region via identical data-offset and data-size
2. defining loader behaviour, meaning a loader MUST be able to read the same region more than once for different configurations
3. defining hash verification, where each node carries its own hash sub-node covering the shared region and verification is performed independently per node
4. defining signing-tool behaviour, requiring that a tool re-signing a FIT with shared regions MUST preserve the sharing across the import/export cycle.

So in my view, we may need to consider other pros and cons for a final decision unless there is another better approach

Currently what I have in my mind why my approach may be better are

• Long-term Maintainability
  • Reference subnode: Adding a new board means adding a new config with a small subnode (3-4 properties). The /images section stays stable regardless of how many boards you support. If you update the kernel binary, you change one image node and all boards pick it up. The ITS source directly expresses the intent: "for this board, use this binary, but place it here."
  • External data with deduplication: Adding a new board means adding a full new image node in /images, repeating type, arch, os, compression, load, entry, and a hash-1 subnode. For M boards and N image types you have M*N full image nodes. Updating the kernel binary means updating M nodes. The relationship between board variants of the same binary is implicit in naming conventions, not structural. The /images section becomes harder to read as board count grows.
• Extensibility
  • Reference subnode: The subnode is a general-purpose container for any per-config override. Future additions (per-config boot arguments, compatible string overrides, compression hints) can be added as new properties in the same subnode with no new mechanism needed or probably small changes.
  • External data with deduplication: Only addresses the load/entry address problem by placing them in separate image nodes. Any other per-config override would require a completely different mechanism. It is a relatively narrow solution to one specific problem rather than a general model.

We tripped over the fact yesterday that mkimage(1) sorts hashed-nodes according to sign-images order instead of actual hashing order (which is device tree order).

I meant to add unsorted here (for hashed-nodes), but adding it for sign-images in addition is fine as well.

OK, please check again

I don't see any change? https://github.com/open-source-firmware/flat-image-tree/compare/e407dc965c43aa1cf91c2220a45d198287c2f96f..fef1b5b1cc00fb4b1d9009c506591629118eebaf

Try now?